Skip to main content
Envía el siguiente estado de fulfillment de un pedido ya placed. Usa las etiquetas configuradas para este comercio (por ejemplo PREPARING o DELIVERED). Fire spark no acepta un enum fijo de cocina.
Requiere un access token con el scope orders:write. Consulta Token para obtener un token.

​
Cómo encaja en el flujo

  1. Tras el checkout, Fire spark envía un webhook cuando el pedido llega a un estado al que te suscribiste.
  2. Tu POS crea el ticket cuando llega order.status.changed con data.status injecting (o el estado que uses para el traspaso).
  3. Cada evento posterior de cocina debe hacer PATCH del siguiente estado de fulfillment. Fire spark actualiza el pedido y puede enviar otro webhook.
  4. La llamada es asíncrona. Reclama el avance mientras el fulfillment está en WAITING y responde sin esperar al siguiente nodo, así que puedes llamarla desde el manejador del webhook. El pedido de la respuesta puede seguir siendo el snapshot de antes de este avance. Un 409 significa que la fila no estaba en WAITING.

​
Cuándo llamar este endpoint

Las etiquetas de abajo son ejemplos. Usa los estados de fulfillment de tu comercio.
Un pedido puede estar en más de un estado de fulfillment a la vez (por ejemplo cocina y delivery). Envía el siguiente estado del trabajo que avanzas. Los demás estados en curso siguen hasta que los actualices.

​
Parámetros de ruta

​
Cuerpo de la solicitud

​
Marcar el pedido como pagado

Mientras el pedido está en PAYING, envía fulfillment_status PAID cuando tu POS haya cobrado. Fire spark marca como pagados los tenders de ese paso (una captura por tender, como si marcaras cada uno como cobrado). El pedido avanza a PAID solo cuando todos los tenders del paso están saldados. Un canje reservado cuenta como saldado; Fire spark confirma los canjes.
  • Sin tenders: se marcan como pagados todos los tenders que el paso aún espera, y el pedido avanza. Es el camino de todos a la vez.
  • Con tenders, y el paso tiene un solo tender: ese tender se marca pagado si completed es true, y el pedido avanza. El mismo comportamiento de antes.
  • Con tenders, y el paso tiene más de un tender: solo cambian los elementos con completed: true. Los que no envías se quedan como están. El pedido no avanza hasta que cada tender del paso está en PAID, contando los de esta llamada. Repite la misma llamada para cada tender. La última avanza el pedido. Las anteriores responden 200, no un error.
Solo puedes marcar tenders IDLE o PENDING que cobran dinero. Un tender que ya está PAID no se captura otra vez. Un id desconocido, o uno que no es de este pedido, responde 404 TENDER_NOT_FOUND. Mientras queden tenders pendientes, la respuesta trae el pedido en data y además:
pendingTenders es una cantidad. Si queda uno, el mensaje dice “1 tender still pending”. Cuando la llamada que completa el conjunto avanza el pedido, los mismos campos vuelven con pendingTenders 0, transitioned true y el mensaje Tender updated. Order transitioned to PAID. Actualizar solo un tender no envía un webhook del pedido ni un evento de realtime. Esos salen solo cuando el pedido sí avanza, después de que ese paso terminó su propio trabajo.
Repetir la misma solicitud es seguro: cada intento de un tender se captura una sola vez. La respuesta trae el pedido actual. El avance es asíncrono, así que ese body puede seguir siendo el snapshot de antes del estado que acabas de enviar.
Combina este endpoint con los webhooks de pedidos: el webhook entrega el pedido cuando llega a un estado suscrito; este endpoint es cómo tu POS reporta el resto del camino en cocina. No envíes un estado terminal (FULFILLED, VOIDED, REVERSED, REFUNDED) — esos nodos se entran solos. Tras el último estado de cocina o entrega (por ejemplo DELIVERED), Fire spark entra a FULFILLED. Si un callback agota los reintentos, entra a VOIDED (sin pago) o REVERSED (pagado). Cancelar y reembolsar desde el dashboard sí llegan a esos terminales.

​
Errores